normalized_query is a single per-backend buffer that can become stale or be overwritten before it is consumed. In particular: (1) PschPostParseAnalyze() can run for statements that later hit the early-return path in PschExecutorEnd() (e.g. queryId == 0), leaving normalized_query set; the next captured query will then incorrectly use this stale normalized text. (2) nested statements (SPI / functions) can overwrite normalized_query before the outer statement reaches ExecutorEnd, causing the outer event to lose normalization or pick up the inner query’s text. Consider storing normalized text in a stack keyed by nesting_level, or in a small per-backend map keyed by queryId/statement identity, and ensure the entry is removed on all completion paths (including the PschExecutorEnd() early return and utility paths).

CaptureLogEvent() copies from normalized_query but never frees/clears it. If an error occurs before the normal query event is built (or if the statement never reaches ExecutorEnd), this leaks TopMemoryContext memory and can cause later events to reuse the wrong normalized text. After copying into event.query, clear the stored normalized buffer (or pop the current entry if switching to a per-statement stack/map).

norm_query_buflen sizing (query_len + clocations_count * 10) is not a guaranteed upper bound once you account for the optional squashed-list suffix (" /*, ... */") and larger $N values. Combined with the use of sprintf(), this can lead to a write past the end of norm_query before the later Assert() triggers. Use a dynamically-growing buffer (e.g., StringInfo) or compute a strict upper bound and write with snprintf() using the remaining capacity, erroring out safely if it would overflow.

The helper comment says it "Uses queryid to identify the specific query", but get_captured_query() actually selects the most recent non-extension query by timestamp (no queryid filtering). Either update the comment to match the implementation or add a queryid filter (e.g., capture pg_stat_activity.query_id/pg_query_id() equivalent) to make the selection deterministic when multiple statements are exported close together.

core_yy_extra_type yyextra is uninitialized when passed to scanner_init(). If scanner_init() doesn’t fully overwrite all fields, this risks undefined behavior. Consider zero-initializing yyextra before calling scanner_init().

CopyQueryText() uses consume=false when calling PschCopyNormalizedQueryForStatement(), so normalized entries remembered at parse time are never removed on the successful path. Since those entries live in TopMemoryContext and are keyed by raw source_text, sessions that execute many literal-variant statements can accumulate entries and grow backend memory without bound. Consider consuming/removing entries after enqueue (when safe) and/or adding an eviction/size cap (or keying by queryId) to prevent unbounded growth.

If PschCopyNormalizedQueryForLog() can’t find a match, the code falls back to copying debug_query_string verbatim into the event, which can still include raw literals (passwords/PII). This contradicts the PR description’s claim that “no raw parameter values are ever captured”. If the intent is a hard guarantee, consider emitting an empty/"" query (or gating raw capture behind a GUC) when normalization lookup fails.

SourceTextMatch() treats pointer equality (entry->source_text == source_text) as an unconditional match. Postgres can reuse memory addresses for new query strings across statements (e.g., after memory context resets), so pointer equality alone can incorrectly match a different statement and return the wrong normalized query. Consider removing the pointer fast-path, or at least validating length/content even when pointers match (e.g., compare lengths and memcmp against source_text_copy).

Normalized query entries are always copied with consume=false, and successful executor/utility paths never call ForgetNormalizedStatement(). This makes the per-backend normalized query registry grow without bound over long-lived sessions that execute many distinct statements, which can lead to backend memory bloat. Consider consuming entries by default after they’re used (and only retaining them for known-reuse cases like cached plans/SPI), or enforcing an upper bound/eviction strategy for the registry.